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ABSTRACT 

Two-party secure function evaluation (SFE) has become sig¬ 
nificantly more feasible, even on resource-constrained de¬ 
vices, because of advances in server-aided computation sys¬ 
tems. However, there are still bottlenecks, particularly in the 
input validation stage of a computation. Moreover, SFE re¬ 
search has not yet devoted sufficient attention to the impor¬ 
tant problem of retaining state after a computation has been 
performed so that expensive processing does not have to be 
repeated if a similar computation is done again. This paper 
presents PartialGC, an SFE system that allows the reuse of 
encrypted values generated during a garbled-circuit compu¬ 
tation. We show that using PartialGC can reduce computa¬ 
tion time by as much as 96% and bandwidth by as much as 
98% in comparison with previous outsourcing schemes for 
secure computation. We demonstrate the feasibility of our 
approach with two sets of experiments, one in which the 
garbled circuit is evaluated on a mobile device and one in 
which it is evaluated on a server. We also use PartialGC 
to build a privacy-preserving “friend finder” application for 
Android. The reuse of previous inputs to allow stateful eval¬ 
uation represents a new way of looking at SFE and further 
reduces computational barriers. 

1. INTRODUCTION 

Secure function evaluation, or SFE, allows multiple parties 
to jointly compute a function while maintaining input and 
output privacy. The two-party variant, known as 2P-SFE, 
was first introduced by Yao in the 1980s [39] and was largely 
a theoretical curiosity. Developments in recent years have 
made 2P-SFE vastly more efficient [18, 27, 38]. However, 
computing a function using SFE is still usually much slower 
than doing so in a non-privacy-preserving manner. Garbled 
circuits, described by Yao, are a powerful mechanism for 
performing SFE, with modern variants allowing malicious 
security for complex programs. 

As mobile devices become more powerful and ubiquitous, 
users expect more services to be accessible through them. 
When SFE is performed on mobile devices (where resource 
constraints are tight), it is extremely slow - if the com¬ 
putation can be run at all without exhausting the mem¬ 
ory, which can happen for non-trivial input sizes and algo¬ 
rithms [8]. One way to allow mobile devices to perform SFE 
is to use a server-aided computational model [8, 22], allow¬ 
ing the majority of an SFE computation to be “outsourced” 
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to a more powerful device while still preserving privacy. Past 
approaches, however, have not considered the ways in which 
mobile computation differs from the desktop. Often, the mo¬ 
bile device is called upon to perform incremental operations 
that are continuations of a previous computation. 

Consider, for example, a friend finder application where 
the location of users is updated periodically to determine 
whether a contact is in proximity. Traditional applications 
disclose location information to a central server. A privacy¬ 
preserving friend finder could perform these operations in a 
mutually oblivious fashion. However, every incremental lo¬ 
cation update would require a full re-evaluation of the func¬ 
tion with fresh inputs in a standard SFE solution. Our ex¬ 
amination of an outsourced SFE scheme for mobile devices 
by Carter et al. [8] (hereon CMTB), determined that the 
cryptographic consistency checks performed on the inputs 
to an SFE computation themselves can constitute the great¬ 
est bottleneck to performance. 

Additionally, many other applications require the ability 
to save state, a feature that current garbled circuit imple¬ 
mentations do not possess. The ability to save state and 
reuse an intermediate value from one garbled circuit execu¬ 
tion to another would be useful in many other ways, e.g ., we 
could split a large computation into a number of smaller 
pieces. Combined with efficient input validation, this be¬ 
comes an extremely attractive proposition. 

In this paper, we show that it is possible to reuse an en¬ 
crypted value in an outsourced SFE computation (we use 
a cut-and-choose garbled circuit protocol) even if one is re¬ 
stricted to primitives that are part of standard garbled cir¬ 
cuits. Our system, PartialGC, which is based on CMTB, 
provides a way to take encrypted output wire values from 
one SFE computation, save them, and then reuse them as 
input wires in a new garbled circuit. Our method vastly re¬ 
duces the number of cryptographic operations compared to 
the trivial mechanism of simply XOR’ing the results with a 
one-time pad, which requires either generating inside the cir¬ 
cuit, or inputting, a very large one-time pad, both complex 
operations. Through the use of improved input validation 
mechanisms proposed by shelat and Shen [38] (hereon sS13) 
and new methods of partial input gate checks and evalu¬ 
ation, we improve on previous proposals. There are other 
approaches to the creation of reusable garbled circuits [13, 
10, 5], and previous work on reusing encrypted values in the 
ORAM model [30, 11, 31], but these earlier schemes have 
not been implemented. By contrast, we have implemented 
our scheme and found it to be both practical and efficient; 
we provide a performance analysis and a sample application 




Figure 1: PartialGC Overview. E is evaluator and G is gen¬ 
erator. The blue box is a standard execution that produces 
partial outputs (garbled values); yellow boxes represent exe¬ 
cutions that take partial inputs and produce partial outputs. 
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Figure 2: Our system has three parties. Only the cloud and 
generator have to save intermediate values - this means that 
we can have different phones in different computations. 


encrypted value, using only garbled circuits, by mapping 
one garbled value into another. 

2. Reduced Runtime and Bandwidth - We show how reusable 
encrypted values can be used in practice to reduce the 
execution time for a garbled-circuit computation; we get 
a 96% reduction in runtime and a 98% reduction in band¬ 
width over CMTB. tmpressively, we can reduce the amount 
of bandwidth required by the mobile party arbitrarily 
when no input checks have to be performed on the partial 
(intermediate) inputs in our protocol. 

3. Outsourcing Stateful Applications - We show how our sys¬ 
tem increases the scope of SFE applications by allowing 
multiple evaluating parties over a period of time to op¬ 
erate on the saved state of an SFE computation without 
the need for these parties to know about each other. 

The remainder of our paper is organized as follows: Section 2 
provides some background on SFE. Section 3 introduces the 
concept of partial garbled circuits in detail. The PartialGC 
protocol and its implementation are described in Section 4, 
while its security is analyzed in Section 5. Section 6 evalu¬ 
ates PartialGC and introduces the friend finder application. 
Section 7 discusses related work and Section 8 concludes. 


to illustrate its feasibility (Section 6), as well as a simplified 
example execution (Appendix C). 

By breaking a large program into smaller pieces, our sys¬ 
tem allows interactive f/O throughout the garbled circuit 
computation. To the best of our knowledge this is the first 
practical protocol for performing interactive f/O in the mid¬ 
dle of a cut-and-choose garbled circuit computation. 

Our system comprises three parties - a generator, an eval¬ 
uator, and a third party (“the cloud”), to which the evaluator 
outsources its part of the computation. Our protocol is se¬ 
cure against a malicious adversary, assuming that there is 
no collusion by either party with the cloud. We also provide 
a semi-honest version of the protocol. 

Figure 1 shows how PartialGC works at a high level: First, 
a standard SFE execution (blue) takes place, at the end of 
which we “save” some intermediate output values. All further 
executions use intermediate values from previous executions, 
tn order to reuse these values, information from both parties 
- the generator and the evaluator - has to be saved, tn our 
protocol, it is the cloud - rather than the evaluator - that 
saves information. This allows multiple distinct evaluators 
to participate in a large computation over time by saving 
state in the cloud between different garbled circuit execu¬ 
tions. For example, in a scenario where a mobile phone is 
outsourcing computation to a cloud, PartialGC can save the 
encrypted intermediate outputs to the cloud instead of the 
phone (Figure 2). This allows the phones to communicate 
with each other by storing encrypted intermediate values in 
the cloud, which is more efficient than requiring them to 
directly participate in the saving of values, as required by 
earlier 2P-SFE systems. Our friend finder application, built 
for an Android device, reflects this usage model and allows 
multiple friends to share their intermediate values in a cloud. 
Other friends use these saved values to check whether or not 
someone is in the same map cell as themselves without hav¬ 
ing to copy and send data. 

By incorporating our optimizations, we give the following 
contributions: 

1. Reusable Encrypted Values - We show how to reuse an 


2. BACKGROUND 

Secure function evaluation (SFE) addresses scenarios where 
two or more mutually distrustful parties Pi ,..., P n , with 
private inputs xi ,..., x n , want to compute a given function 
y% — f(xi, ..., x n ) (yi is the output received by Pi), such 
that no Pi learns anything about any Xj or yj, i % j that is 
not logically implied by Xi and yi. Moreover, there exists no 
trusted third party - if there was, the PiS could simply send 
their inputs to the trusted party, which would evaluate the 
function and return the yiS. 

SFE was first proposed in the 1980s in Yao’s seminal pa¬ 
per [39]. The area has been studied extensively by the cryp¬ 
tography community, leading to the creation of the first gen¬ 
eral purpose platform for SFE, Fairplay [32] in the early 
2000s. Today, there exist many such platforms [6, 9, 16, 17, 
26,37,40]. 

The classic platforms for 2P-SFE, including Fairplay, use 
garbled circuits. A garbled circuit is a Boolean circuit which 
is encrypted in such a way that it can be evaluated when 
the proper input wires are entered. The party that evaluates 
this circuit does not learn anything about what any partic¬ 
ular wire represents. In 2P-SFE, the two parties are: the 
generator, which creates the garbled circuit, and the evalua¬ 
tor, which evaluates the garbled circuit. Additional crypto¬ 
graphic techniques are used for input and output; we discuss 
these later. 

A two-input Boolean gate has four truth table entries. A 
two-input garbled gate also has a truth table with four en¬ 
tries representing Is and 0s, but these entries are encrypted 
and can only be retrieved when the proper keys are used. 
The values that represent the Is and 0s are random strings 
of bits. The truth table entries are permuted such that the 
evaluator cannot determine which entry she is able to de¬ 
crypt, only that she is able to decrypt an entry. The entirety 
of a garbled gate is the four encrypted output values. 

Each garbled gate is then encrypted in the following way: 
Each entry in the truth table is encrypted under the two 
input wires, which leads to the result, truthi = Enc(input x 11 
inputy ) (B outputi, where truthi is a value in the truth table, 
input x is the value of input wire x, inputy is the value of 




























input wire y, and outputi is the non-encrypted value, which 
represents either 0 or l.We use AES as the Enc function. 
If the evaluator has input x and input y , then she can also 
receive outputi , and the encrypted truth tables are sent to 
her for evaluation. 

For the evaluator’s input, l-out-of-2 oblivious transfers 
(OTs) [1, 20, 34, 35] are used. In a l-out-of-2 OT, one party 
offers up two possible values while the other party selects 
one of the two values without learning the other. The party 
that offers up the two values does not learn which value was 
selected. Using this technique, the evaluator gets the wire 
labels for her input without leaking information. 

The only way for the evaluator to get a correct output 
value from a garbled gate is to know the correct decryption 
keys for a specific entry in the truth table, as well as the 
location of the value she has to decrypt. 

During the permutation stage, rather than simply ran¬ 
domly permuting the values, the generator permutes values 
based on a specific bit in input x and input y , such that, given 
input x and input y the evaluator knows that the location of 
the entry to decrypt is bit x * 2 + bit y . These bits are called 
the permutation bits , as they show the evaluator which en¬ 
try to select based on the permutation; this optimization, 
which does not leak any information, is known as point and 
permute [32]. 

2.1 Threat Models 

Traditionally, there are two threat models discussed in 
SFE work, semi-honest and malicious. The above description 
of garbled circuits is the same in both threat models. In 
the semi-honest model users stay true to the protocol but 
may attempt to learn extra information from the system 
by looking at any message that is sent or received. In the 
malicious model, users may attempt to change anything with 
the goal of learning extra information or giving incorrect 
results without being detected; extra techniques must be 
added to achieve security against a malicious adversary. 

There are several well-known attacks a malicious adver¬ 
sary could use against a garbled circuit protocol. A protocol 
secure against malicious adversaries must have solutions to 
all potential pitfalls, described in turn: 

Generation of incorrect circuits : If the generator does not 
create a correct garbled circuit, he could learn extra infor¬ 
mation by modifying truth table values to output the eval¬ 
uator’s input; he is limited only by the external structure of 
the garbled circuit the evaluator expects. 

Selective failure of input : If the generator does not offer 
up correct input wires to the evaluator, and the evaluator 
selects the wire that was not created properly, the generator 
can learn up to a single bit of information based on whether 
the computation produced correct outputs. 

Input consistency : If either party’s input is not consistent 
across all circuits, then it might be possible for extra infor¬ 
mation to be retrieved. 

Output consistency : In the two-party case, the output con¬ 
sistency check verifies that the evaluator did not modify the 
generator’s output before sending it. 

2.1.1 Non-collusion 

CMTB assumes non-collusion, as quoted below: 

“The outsourced two-party SFE protocol securely computes 
a function f(a,b) in the following two corruption scenarios: 
(l)The cloud is malicious and non-cooperative with respect 


to the rest of the parties, while all other parties are semi- 
honest, (2)All but one party is malicious, while the cloud is 
semi-honest. ” 

This is the standard definition of non-collusion used in 
server-aided works such as Kamara et al. [22]. Non-collusion 
does not mean the parties are trusted; it only means the 
two parties are not working together in order to cheat. In 
CMTB, any individual party that attempts to cheat to gain 
additional information will still be caught, but collusion be¬ 
tween multiple parties could leak information. For instance, 
the generator could send the cloud the keys to decrypt the 
circuit and see what the intermediate values are of the gar¬ 
bled function. 

3. PARTIAL GARBLED CIRCUITS 

We introduce the concept of partial garbled circuits (PGCs), 
which allows the encrypted wire outputs from one SFE com¬ 
putation to be used as inputs to another. This can be ac¬ 
complished by mapping the encrypted output wire values to 
valid input wire values in the next computation. In order to 
better demonstrate their structure and use, we first present 
PGCs in a semi-honest setting, before showing how they can 
aid us against malicious adversaries. 

3.1 PGCs in the Semi-Honest Model 

In the semi-honest model, for each wire value, the gen¬ 
erator can simply send two values to the evaluator, which 
transforms the wire label the evaluator owns to work in an¬ 
other garbled circuit. Depending on the point and permute 
bit of the wire label received by the evaluator, she can map 
the value from a previous garbled circuit computation to a 
valid wire label in the next computation. 

Specifically, for a given wire pair, the generator has wires 
Wq- 1 and rej -1 , and creates wires Wq and w\. Here, t refers 
to a particular computation in a series, while 0 and 1 cor¬ 
respond to the values of the point and permute bits of the 
t — 1 values. The generator sends the values icq -1 ® Wq and 
rcj -1 ® w\ to the evaluator. Depending on the point and 
permute bit of the w\~ x value she possesses, the evaluator 
selects the correct value and then XORs her w^ 1 with the 
(re* -1 ® w\) value, thereby giving her w\, the valid partial 
input wire. 

3.2 PGCs in the Malicious Model 

In the malicious model we must allow the evaluation of a 
circuit with partial inputs and verification of the mappings, 
while preventing a selective failure attack. The following fea¬ 
tures are necessary to accomplish these goals: 

Verifiable Mapping : The generator G is able to create a se¬ 
cure mapping from a saved garbled wire value into a new 
computation that can be checked by the evaluator E, with¬ 
out E being able to reverse the mapping. During the evalua¬ 
tion and check phase, E must be able to verify the mapping 
G sent. G must have either committed to the mappings be¬ 
fore deciding the partition of evaluation and check circuits, 
or never learned which circuits are in the check versus the 
evaluation sets. 

Partial Generation and Partial Evaluation: G creates the 
garbled gates necessary for E to enter the previously output 
intermediate encrypted values into the next garbled circuit. 
These garbled gates are called partial input gates. As shown 




Figure 3: This figure shows how we create a single partial 
input gate for each input bit for each circuit and then link 
the partial input gates to the remainder of the circuit. 

in Figure 3 each garbled circuit is made up of two pieces: the 
partial input gates and the remainder of the garbled circuit. 

Revealing Incorrect Transformations : Our last goal is to let 
E inform G that incorrect values have been detected. With¬ 
out a way to limit leakage, G could gain information based 
on whether or not E informs G that she caught him cheat¬ 
ing. This is a selective failure attack and is not present in 
our protocol. 

4. PARTIALGC PROTOCOL 

We start with the CMTB protocol and add cut-and-choose 
operations from sS13 before introducing the mechanisms 
needed to save and reuse values. We defer to the original 
papers for full details of the outsourced oblivious trans¬ 
fer [8] and the generator’s input consistency check [38] sub¬ 
protocols that we use as primitives in our protocol. 

Our system operates in the same threat model as CMTB 
(see Section 2.1.1): we are secure against a malicious adver¬ 
sary under the assumption of non-collusion. A description of 
the CMTB protocol is available in Appendix A. 

4.1 Preliminaries 

There are three participants in the protocol: 

Generator - The generator is the party that generates the 
garbled circuit for the 2P-SFE. 

Evaluator -The evaluator is the other party in the 2P- 
SFE; it outsources computation to the cloud. 

Cloud - The cloud is the third party that executes the 
garbled circuit outsourced by the evaluator. 

Notation 

Ci - The ith circuit. 

CKeyi - Circuit key used for the free XOR optimization [25]. 
The key is randomly generated and then used as the differ¬ 
ence between the 0 and 1 wire labels for a circuit Ci. 

CSeedi - This value is created by the generator’s PRNG and 
is used to generate a particular circuit Ci. 

POutjfij - The partial output values are the encrypted wire 
values output from an SFE computation. These are encrypted 
garbled circuit values that can be reused in another garbled 
circuit computation, ff is replaced in our protocol descrip¬ 
tion with either a 0, 1, or x, signifying whether it represents a 
0, 1, or an unknown value (from the cloud’s point of view), i 
denotes the circuit the POut value came from and j denotes 
the wire of the POuti circuit. 

PInffij - The partial input values are the re-entered POut 
values after they have been obfuscated to remove the circuit 
key from the previous computation. These values are input 
to the partial input gates. #, i, and j, are the same as above. 


GInffij - The garbled circuit input values are the results 
of the partial input gates and are input into the remaining 
garbled circuit, as shown in Figure 3. #, i, and j, are the 
same as above. 

Partial Input Gates - These are garbled gates that take in 
Pin values and output Gin values. Their purpose is to 
transform the Pin values into values that are under CKeyi 
for the current circuit. 

Algorithm 0: PartialComputation 

Input : Circuit-File, Bit-Security, Number_of_Circuits, Inputs, 
Is_First_Execution 
Output: Circuit File Output 
Cut_and_Choose {is_First_Executiori) 

Eval_Garbled_Input <— Evaluator_Input (EvaLSelect_Bits, 
Possible-EvaLInput ) 

Generat or _ Input _Che ck ( Gen_Input) 

Partial_Garbled_Input Partial_Input {Partial-Outputtime-O 

Garbled_Output, Partial-Output 

Circuit_Execution( Garbled-Input (Gen, Eval, Partial'.)) 
Circuit_Output ( G arbled-Output) 

Part ial_0utput (P artiaPOutput) 


4.2 Protocol 

Each computation is self-contained; other than what is 
explicitly described as saved in the protocol, each value or 
property is only used for a single part of the computation 
(i.e. randomness is different across computations). 

Common Inputs: The program circuit file, the bit level secu¬ 
rity iF, the circuit level security (number of circuits) S, and 
encryption and commitment functions. 

Private Inputs: The evaluator’s input evllnput and genera¬ 
tor’s input genlnput. 

Outputs: The evaluator and generator can both receive gar¬ 
bled circuit outputs. 

Phase 1: Preparation and Cut-and-choose 

Preparation: 

The generator creates two seeds for each circuit Co ... Cs -i , 
CSeedi = {0, 1} K . 

We prepare our circuits such that any output to the gen¬ 
erator or evaluator is output under a one-time pad, en¬ 
crypted inside of the circuit. That is we augment all cir¬ 
cuits such that out ev i = out ev i ® outputKey ev i and out ge n — 
out gen ® outKeygen, where out ev i and out gen is the initial 
output. 

The generator and evaluator’s input is extended to include 
the corresponding output Key and a A-bit secret key for a 
MAC. 

Using the same technique as CMTB for input encoding 
to split the evaluator’s input in K bits, where bitj : o ® • • • © 
bitj,K- 1 = evllnput j for the jth bit of the evaluator’s in¬ 
put. The generator then creates the possible evaluator’s in¬ 
put for each circuit Ci. To create the evaluator’s input, the 
generator creates a key IKeyi = {0, 1} K for the zth cir¬ 
cuit, and a set of seeds, evlInputSeedsOj = {0, 1} K and 
evlInputSeedslj = {0, 1} K , where for 0 <= j < len(evllnput). 
Two seeds are created for each bit, representing 0 and 1. The 
garbled input values are then created: 

garbledlnputEvlOij = hash(evlInputSeedsOj , IKeyi) 
garbledlnputEvllij — hash(evlInputSeedslj,IKeyi) 

As with CMTB, the possible evaluator’s inputs are per¬ 
muted for each different circuit to prevent the cloud from 




Algorithm 1: Cut_and_Choose 

Input : is_First_Execution 
if is_First_Execution then 
|_ circuitSelection <— rand() // bit-vector of size S 

N <— | S' // Number of evaluation circuits 

//Generator creates his garbled input and circuit seeds for each 
circuit 

for i <— 0 to S do 

CSeedi rand () 

garbledGenlnputi <— garble (gen Input, rand()) 

//generator creates or loads keys 
if is-First-Execution then 
I checkKeyi rand() 

| evlKeyi i— rand () 
else 

loadKeys(); 

checkKeyi <— hash(loadedCheckKeyi ) 
evlKeyi <— hash(loadedEvlKeyi ) 

// encrypts using unique one-time XOR pads 
encSeedlni <— CSeedi © evlKeyi 
encGarbledlni <— garbledGenlnputi © checkKeyi 

if is_First_Execution then 

// generator offers input OR keys for each circuit seed 
selectedKeys <— 

OT(circuitSelection, {evlKey, checkKey }) 

else 

|_ loadSelectedKeys() 

for i i — 0 to S do 

genSendToEval (hash (checkKeyi), 
hash(evaluationKeyi)) 

for i 4— 0 to S do 

|_ cloudSendToEval(hash(selectedKeyi), isCheckCircuiti) 

//If all values match, the evaluator learns split, else abort, 
for i 0 to S do 

j isCheckCircuiti 

correct <— (recievedGenij == recievedEvli) 
if /correct then 
|_ abort() 


understanding what the evaluator’s input maps to. The gen¬ 
erator commits to each input value so the cloud will be able 
to verify he did not swap values. 

Cut-and-choose: 

Unlike some other GC protocols we do not commit to the 
various circuits before we execute the cut-and-choose. We 
modify the cut-and-choose mechanism described in sS13 as 
we have an extra party involved in the computation. In this 
cut-and-choose, the cloud selects which circuits are evalua¬ 
tion circuits and which circuits are check circuits, 

circuitSelection = {0, 1} S 

where 0 is an evaluation circuit and 1 is a check circuit. 
N evaluation circuits and S — N check circuits are selected 
(like sS13, we use N = I#). The generator does not learn 
the circuit selection. 

The generator generates garbled versions of his input and 
circuit seeds for each circuit. He encrypts these values us¬ 
ing unique one-time XOR pad key for each circuit. He also 
encrypts the evaluator’s possible input. For 0 < i < S, 

garbledGenlnputi = garble Input (gen Input) 
checkKeyi — {0, 1} K 
evlKeyi — {0, 1} K 
encGarbledlni = garbledGenlnputi ® evlKeyi 
encSeedlni = CSeedi ® checkKeyi 
enelnputEvl = garbledlnputEvl ® checkKeyi 


where garblelnput() takes in the input, and produces a vec¬ 
tor of {0, 1} K bit strings, one for each bit of the generator’s 
input for a given Ci and garbledlnputEvl is the garbled in¬ 
put 

(garbledInputEvlOi,o\ \ ... \\garbledInputEvlOig e n-i 
WgarbledlnputEvlli^o || ... \ \garbledInputEvllig en -i) 
and len is the length of evlInput. 

The cloud and generator perform an oblivious transfer 
where the generator offers up decryption keys for his input 
and decryption keys for the circuit seed and possible eval¬ 
uator’s input for each circuit. The cloud can select the key 
to decrypt the generator’s input or the key to decrypt the 
circuit seed and possible evaluator’s input for a circuit but 
not both. 

selectedKeys — OT (circuit Selection, {evlKey , checkKey}) 

For each circuit, if the cloud selects the decryption key for 
the circuit seed and possible evaluator’s input in the obliv¬ 
ious transfer, then the circuit is used as a check circuit. If 
the cloud selects the key for the generator’s input then the 
circuit is used as an evaluation circuit. 

The generator sends the encrypted garbled inputs and 
check circuit information for all circuits to the cloud. The 
cloud decrypts the information he can decrypt using its keys. 
Both the cloud and generator save the decryption keys so 
they can be used in future computations, which use saved 
values. 

The evaluator must also learn the circuit split. The generator 
sends a hash of each possible encryption key the cloud could 
have selected to the evaluator for each circuit as an ordered 
pair. For 0 < i < S, 

genSend(hash(checkKeyi ), hash(evaluationKeyi)) 

The cloud sends a hash of the value received to the evaluator 
for each circuit. The cloud also sends bits to indicate which 
circuits were selected as check or evaluation circuits to the 
evaluator. For 0 < i < S, 

cloudSend(hash(selectedKeyi), isCheckCircuiti) 

The evaluator compares the hash the cloud sent to one of 
the hashes the generator sent, which is selected by the circuit 
selection sent by the cloud. For 0 < i < S, 

j = isCheckCircuiti 
correct = (receivedGenij == receivedEvli) 

If all values match, the evaluator uses the isCheckCircuiti 
to learn the split between check and evaluator circuits. Oth¬ 
erwise, abort. 

We only perform the cut-and-choose oblivious transfer for 
the initial computation. For any subsequent computations, 
the generator and evaluator hash the saved decryption keys 
and use those hashes as the new encryption and decryption 
keys. The circuit split selected by the cloud is saved and 
stays the same across computations. 

At the conclusion of this step (1) the cloud has all the 
information to evaluate the evaluation circuits when they 
are sent by the generator, i.e. the generator’s input for each 
evaluation circuit, (2) the cloud has all the information to 
validate the check circuits when the generator sends those 
over, i.e., each circuit seed and the possible evaluator’s input 
for the check circuits (3) the cloud and evaluator know the 
check and evaluation circuit split, (4) the generator does not 
know the circuit split. 



Phase 2: Evaluator’s Input and Oblivious Transfer 


Algorithm 2: Evaluator_Input 

Input : Eval_Select_Bits, Possible_Eval_Input 
Output: EvaLGarblecLInput 

// cloud gets selected input wires // generator offers both 
possible input wire values for each input wire; evaluator selects 
its input 

outSeeds = BaseOOT{bitsEvl, possiblelnputs). 

// the generator sends unique IKey values for each circuit to the 
evaluator 

for i 0 to S do 

|_ genSendToEval(IKeyi) 

// the evaluator sends IKey values for all evaluation circuits to 
the cloud 

for i ^— 0 to S do 

if HsCheckCircuit(i) then 
|_ EvalSendToCloud(I Keyi) 

// cloud uses this to learn appropriate inputs 
for i 0 to S do 

for j <— 0 to len(evlInputs) do 
if HsCheckCircuit(i) then 
|_ inputEvlij hash(IKeysi, outSeeds j) 

return inputEvl 


We use the base outsourced oblivious transfer (00T) of 
CMTB. In CMTB’s 00T, the evaluator enters in the inputs 
buts and the generator enters in both possible inputs. The 
evaluator and generator perform a single OT operation be¬ 
fore extending it, using the Ishai OT extension, to all the 
input bits. 

After extending it across each input bit, it is then ex¬ 
tended across each garbled circuit using the same technique 
described in the algorithm. After the OOT is finished, the 
cloud has the selected input wire values, which represent the 
evaluator’s input. 

As with CMTB, which uses the results from a single OOT 
as seeds to create the evaluator’s input for all circuits, the 
cloud in our system also uses seeds from a single base OT 
(called “BaseOOT” below) to generate the input for the eval¬ 
uation circuits. The cloud receives the seeds for each input 
bit selected by the evaluator. 

outSeeds = B aseOOT(evl Input, evl Input Seeds). 

where outSeeds are the seeds selected by the evaluator’s 
input. 

The generator sends the IKeyi keys (from phase 1) to 
the evaluator for each circuit. The evaluator sends the keys 
for the evaluation circuits to the cloud. The cloud then uses 
these keys and the outSeeds to attain the evaluator’s in¬ 
put. For 0 < i < S, for 0 < j < len(evl Inputs) where 
\isCheckCircuit(i), 

inputEvkj = hash(IKeyi,outSeedsj) 

Phase 3: Generator’s Input Consistency Check 

We use the input consistency check of sS13. In this check, 
a universal hash is used to prove consistency of the genera¬ 
tor’s input across each evaluation circuit (attained in phase 
1). Simply put, if any hash is different in any of the evalua¬ 
tion circuits, we know the generator did not enter consistent 
input. More formally, a hash of the generator’s input is taken 
for each circuit. For 0 < i < S where \isCheckCircuit(i), 

ti — U HF(garbledGenInputi,Ci) 


Algorithm 3: Generator_Input_Check 
Input : Generator_Input 

// The cloud takes a hash of the generator’s input or each 
evaluation circuit for i 0 to S do 
if isCheckCircuit(i) then 
\_ ti <— UHF(garbledGenInputi) 

//If a single hash is different then the cloud knows the generator 
tried to cheat. 

correct <— ((to == ti)&(to == £ 2 )^: . . . &(to == tjv— 1 )) 
if ! correct then 
|_ abort() 


The results of these universal hashes are compared. If a sin¬ 
gle hash is different then the cloud knows the generator tried 
to cheat. 

correct — ((to- ti)8z(to -£ 2 )^ • • • &(to-tjv- 1 )) 

Phase 4: Partial Input Gate Generation, Check, and 
Evaluation 

Generation : 

For 0 < i < S, for 0 < j < len(savedWires) the gener¬ 
ator creates a partial input gate, which transforms a wire’s 
saved values, POutOij and POutlij, into values that can 
be used in the current garbled circuit execution, GInOij and 
GInlij. 

For each circuit 0 < i < S, the generator creates a pseu¬ 
dorandom transformation value Ri = {0, 1} K , to assist with 
the transformation. 

For each set of POutOij and POutlij, the generator 
XORs each value with Ri. Both results are then hashed, and 
put through a function to determine the new permutation 
bit, as hashing removes the old permutation bit. 

tO = hash(POutOij ® Ri) 
tl — hash(POutlij ® Ri) 

PInOij, PInlij = setPPBitGen(tO, tl) 

This function, setPPBitGen, pseudo-randomly finds a bit 
that is different between the two values of the wire and notes 
that bit to be the permutation bit. setPPBitGen is seeded 
from CSeedi, allowing the cloud to regenerate these values 
for the check circuits. 

For each PInOij, PInlij pair, a set of values, GInOij 
and GInlij, are created under the master key of Ci - where 
CKeyi is the difference between 0 and 1 wire labels for the 
circuit. In classic garbled gate style, two truth table values, 
TTOij and TTlij, are created such that: 

TTOij ® PInOij = GInOij 
TTUj © PlnUj = GInlij 

The truth table, TTOij and TTlij, is permuted so that 
the permutation bits of PInOij and PInlij tell the cloud 
which entry to select. Each partial input gate, consisting of 
the permuted TTO^j, TTlij values, the bit location from 
setPPBitGen, and each Ri, is sent to the cloud. 

Check: 

For all the check circuits, [i.e., Vi : 0 < i < S where 
isCheckCircuit(i) is true), for 0 < j < len(savedWires), 
the cloud receives the truth table information, TTOij, TTli^, 
and bit location from setPPBitGen, and proceeds to re¬ 
generate the gates based on the check circuit information. 
The cloud uses Ri (sent by the generator), POutOij and 



Algorithm 4: PartiaLInput 

Input : Partial-Output 
Output: Partial_Garbled_Input 

// Generation: the generator creates a partial input gate , which 
transforms a wire’s saved values, POutOij and POutlij , into 
values that can be used in the current garbled circuit execution, 
GInOij and GInlij. 
for i 0 to S do 

Ri PRNG.random() 

for j 0 to len(savedWires) do 
tO hash(POutOij © Ri) 
tl <— hash{POutlij © Ri) 

PInOij,PInlij <— setPPBitGen(tO,tl) 

GInOij i — TTOij © PInOij 
Glnl-j <- TTUj © PInlij 
GenSendToCloud( Permute( [TTOij, TTlij]), 
permute_bit_locations ) 

GenSendToCloud(i?^) 

// Check: The cloud checks the gates to make sure the generator 

didn’t cheat 

for i <— 0 to S do 

if isCheckCircuit(i) then 

for j 4— 0 to len(savedWires) do 

// the cloud has received the truth table 
information, TTOij , TTlij , bit locations from 
setPPBitGen , and Ri 

correct ( generateGateFromInfo () == 

receivedGateFromGen{)) 

// If any gate does not match, the cloud knows the 
generator tried to cheat, 
if !correct then 
|_ abort(); 

// Evaluation 
for i <— 0 to S do 

if HsCheckCircuit(i) then 

for j 4— 0 to len(savcdWires) do 

//The cloud, using the previously saved POutXij 
value, and the location (point and permute) bit sent 
by the generator, creates PInxij 
PInxij <(— 

setPPBitEval(hash(Ri © POutXij ), location) 

// Using PInxij, the cloud selects the proper 
truth table entry TTxij from either TTOij or 
TTlij to decrypt 

// Creates Glnxij to enter into the garbled circuit 

GInxij <— TTxij © POutxij 

return Gin; 


POutXij (saved during the previous execution), and CSeedi 
(recovered during the cut-and-choose) to generate the par¬ 
tial input gates in the same manner as described previously. 
The cloud then compares these gates to those the genera¬ 
tor sent. If any gate does not match, the cloud knows the 
generator tried to cheat. 

Evaluation : 

For 0 < i < S where MsCheckCircuit(i ), for 0 < j < 
len(savedWires) the cloud receives the truth table informa¬ 
tion, TTaij,TTbij and bit location from setPPBitGen. a 
and b are used to denote the two permuted truth table val¬ 
ues. The cloud, using the previously saved POutXij value, 
creates the Plnxij value 

Plnxij — setPPBitEval(hash(Ri ® POutXij), location) 

where location is the location of the point and permute 
bit sent by the generator. Using the point and permute 
bit of PInxij , the cloud selects the proper truth table en¬ 
try TTxij from either TTaij or TTbij to decrypt, creates 
GInxij and then enters Glnxij into the garbled circuit. 

Glnxij = TTxij © POutXij 


Phase 5: Circuit Generation and Evaluation 


Algorithm 5: Circuit_Execution 

Input : Generator-Input, Evaluator_Input, Partial-Input 
Output: Partial-Output, GarblecLOutput 

// The generator generates each garbled gate and sends it to the 
cloud. Depending on whether the circuit is a check or evaluation 
circuit, the cloud verifies that the gate is correct or evaluates the 
gate. 

for i 0 to S do 

| for j 0 to len(circuit) do 
g genGate(Ci, j) 
send(g) 

// the cloud receives all gates for all circuits, and then checks 
OR evaluates each circuit 
for i 0 to S do 

for j 0 to len(circuit) do 
g recvGateQ 
if isCheckCircuit(i) then 

if / verifyCorrect(g) then 
|_ abort() 

else 

|_ eval(g) 

return Partial-Output, Garbled_Output 


Circuit Generation : 

The generator generates every garbled gate for each circuit 
and sends them to the cloud. Since the generator does not 
know the check and evaluation circuit split, nothing changes 
between the generation for check and evaluation circuits. For 
0 < i < S, For 0 < j < len{circuit ), 

g — garbleGate(Ci, j) 

send(g) 

Circuit Evaluation and Check : 

The cloud receives garbled gates for all circuits. For eval¬ 
uation circuits the cloud evaluates those garbled gates. For 
check circuits the cloud generates the correct gate, based 
on the circuit seed, and is able to verify it is correct. For 
0 < i < S, For 0 < j < len(circuit ), 

g = recvGateQ 
if(isCheckCircuit(i )) verifyCorrect(g) 

else eval(g) 

If a garbled gate is found not to be correct, the cloud 
informs the evaluator and generator of the incorrect gate 
and safely aborts. 

Phase 6: Output and Output Consistency Check 


Algorithm 6: Circuit_Output 

Input : Garbled_Output 

//a MAC of the output is generated inside the garbled circuit, 

and both the resulting garbled circuit output and the MAC are 

encrypted under a one-time pad. 

outEvlC omplete = outEvl\\M AC (outEvl) 

result = (outEvlM AC == M AC (outEvl)) 

if /result then 

|_ abort() // output check fail 


As the final step of the garbled circuit execution, a MAC 
of the output is generated inside the garbled circuit, based 
on a k- bit secret key entered into the function. 

outEvlC omplete = outEvl\\M AC (outEvl) 



Both the resulting garbled circuit output and the MAC are 
encrypted under the one-time pad (from phase 1 before) 
leaving the garbled circuit. 

To receive output from the garbled circuit for any particu¬ 
lar output bit x, a majority vote is taken across all evaluation 
circuits. For 0 < i < S where \isCheckCircuit(i ), 

result = majority(COuto, x . •. COuti- i jX ) 

Where COutij is the output bits, i is the zth circuit and 
j is the j th output bit from circuit i. 

The cloud sends the corresponding encrypted (under the 
one-time pad introduced in phase 1) output to each party. 

The generator and evaluator then decrypt the received 
ciphertext by using their one-time pad keys and perform 
a MAC over real output to verify the cloud did not modify 
the output by comparing the generated MAC with the MAC 
calculated within the garbled circuit. 

result — (outEvlMAC == M AC (outEvl)) 

Both parties, the generator and evaluator, now have their 
output. 

Phase 7: Partial Output 


Algorithm 7: PartiaLOutput 

Input : PartiaLOutput 

for i 0 to S do 

for j 4— 0 to len(PartiaLOutput) do 

//The generator saves both possible wire values 
GenSave(PartiaLOutputOi j) 
GenS&ve^PartiaLOutputlij ) 

for i e 0 to S' do 

for j 4— 0 to len(PartiaLOutput) do 
if isCheckCircuit(i) then 
I PvlS&ve^PartiaLOutputOij ) 

| Pv\S&ve(PartiaLOutputlij) 

else 

// circuit is evaluation circuit 
PvlSave(PartiaLOutputXij) 


The generator saves both possible wire values for each 
partial output wire. For each evaluation circuit the cloud 
saves the partial output wire value. For check circuits the 
cloud saves both possible output values. 

4.3 Implementation 

As with most garbled circuit systems there are two stages 
to our implementation. The first stage is a compiler for cre¬ 
ating garbled circuits, while the second stage is an execution 
system to evaluate the circuits. 

We modified the compiler from Kreuter et al. [27] (hereon 
KSS12 compiler) to allow for the saving of intermediate wire 
labels and loading wire labels from a different SFE compu¬ 
tation. By using the KSS12 compiler, we have an added ben¬ 
efit of being able to compare circuits of almost identical size 
and functionality between our system and CMTB, whereas 
other protocols compare circuits of sometimes vastly differ¬ 
ent sizes. 

For our execution system, we started with the CMTB sys¬ 
tem and modified it according to our protocol requirements. 
PartialGC automatically performs the output consistency 
check, and we implemented this check at the circuit level. 
We became aware and corrected issues with CMTB relat¬ 
ing to too many primitive OT operations (S * inputs instead 


inputs) performed in the outsourced oblivious transfer when 
using a high circuit parameter and too low a general security 
parameter ( log 2 {input ) instead of 80). The fixes reduced the 
run-time of the OOT, though the exact amount varied. 

5. SECURITY OF PARTIALGC 

In this section, we provide a proof of the PartialGC pro¬ 
tocol, showing that our protocol preserves the standard se¬ 
curity guarantees provided by traditional garbled circuits - 
that is, none of the parties learns anything about the pri¬ 
vate inputs of the other parties that is not logically implied 
by the output it receives. Section 5.1 provides a high-level 
overview of the proof. Section 5.2 goes over models and def¬ 
initions, followed by security guarantees in Section 5.3 and 
a full proof in Section 5.4. 

5.1 Proof Sketch 

We know that the protocol described in CMTB allows 
us to garble individual circuits and securely outsource their 
evaluation. In this paper, we modify certain portions of the 
protocol to allow us to transform the output wire values 
from a previous circuit execution into input wire values in a 
new circuit execution. These transformed values, which can 
be checked by the evaluator, are created by the generator 
using circuit “seeds.” 

We also use some aspects of sS13, notably their novel cut- 
and-choose technique which ensures that the generator does 
not learn which circuits are used for evaluation and which 
are used for checking - this means that the generator must 
create the correct transformation values for all of the cut- 
and-choose circuits. 

Because we assume that the CMTB garbled circuit scheme 
can securely garble any circuit, we can use it individually on 
the circuit used in the first execution and on the circuits used 
in subsequent executions. We focus on the changes made at 
the end of the first execution and the beginning of subse¬ 
quent executions which are introduced by PartialGC. 

The only difference between the initial garbled circuit ex¬ 
ecution and any other garbled circuit in CMTB is that the 
output wires in an initial PartialGC circuit are stored by the 
cloud, and are not delivered to the generator or the evalua¬ 
tor. This prevents them from learning the output wire labels 
of the initial circuit, but cannot be less secure than CMTB, 
since no additional steps are taken here. 

Subsequent circuits we wish to garble differ from ordinary 
CMTB garbled circuits only by the addition, before the first 
row of gates, of a set of partial input gates. These gates don’t 
change the output along a wire, but differ from normal gar¬ 
bled gates in that the two possible labels for each input wire 
are not chosen randomly by the generator, but are derived 
by using the two labels along each output wire of the initial 
garbled circuit. 

This does not reduce security. In PartialGC, the input 
labels for partial input gates have the same property as the 
labels for ordinary garbled input gates: the generator knows 
both labels, but does not know which one corresponds to the 
evaluator’s input, and the evaluator knows only the label 
corresponding to its input, but not the other label. This is 
because the evaluator’s input is exactly the output of the 
initial garbled circuit, the output labels of which were saved 
by the evaluator. The evaluator does not learn the other 
output label for any of the output gates because the output 
of each garbled gate is encrypted. If the evaluator could learn 




any output labels other than those which result from an 
evaluation of the garbled circuit, the original garbled circuit 
scheme itself would not be secure. 

The generator, which also generated the initial garbled 
circuit, knows both possible input labels for all partial eval¬ 
uation gates, because it has saved both potential output 
labels of the initial circuit’s output gates. Because of the 
outsourced oblivious transfer used in CMTB, the generator 
did not know which input labels to use for the initial garbled 
circuit, and therefore will not have been able to determine 
the output labels for that circuit. Therefore, the generator 
will likewise not know which input labels are being used for 
subsequent garbled circuits. 

5.2 Model and definitions 

Throughout our protocol, we assume that none of the par¬ 
ties involved ever collude with the cloud. It is known that 
theoretical limitations exist when considering collusion in 
secure multiparty computation, and other schemes consid¬ 
ering secure computation with multiple parties require sim¬ 
ilar restrictions on who and how many parties may collude 
while preserving security. If an outsourcing protocol is se¬ 
cure when both the generator and the cloud are malicious 
and colluding, this implies a secure two-party scheme where 
one party has sub-linear work with respect to the size of the 
circuit, which is currently only possible with fully homo¬ 
morphic encryption [22]. However, making the assumption 
that the cloud will not collude with the participating parties 
makes outsourcing securely a theoretical possibility. 

While it is unlikely that a reputable cloud provider would 
allow external parties to illegally control or modify computa¬ 
tions within their systems, we cannot assume the cloud will 
automatically be semi-honest. For example, our protocol re¬ 
quires a number of consistency checks to be performed by 
the cloud that ensure the participants do not cheat. Without 
mechanisms to force the cloud to make these checks, a “lazy” 
cloud provider could save resources by simply returning that 
all checks verified without actually performing them. 

The work of Kamara et al. [22] formalizes the idea of a 
non-colluding cloud based on the ideal-model/real-model se¬ 
curity definitions common in secure multiparty computa¬ 
tion. We apply their definitions to our protocol (for the two- 
party case in particular) as described below. 

Real-model execution. The protocol takes place between 
two parties (Pi,P2) executing the protocol and a server P3, 
where each of the executing parties provides input x \, aux¬ 
iliary input Zi, and random coins r\. The server provides 
only auxiliary input Z 3 and random coins r 3 . There exists 
some subset of independent parties (Hi, ..Am), m < 3 that 
are malicious adversaries. Each adversary corrupts one ex¬ 
ecuting party and does not share information with other 
adversaries. For all honest parties, let OUTi be its output, 
and for corrupted parties let OUTi be its view of the pro¬ 
tocol execution. The i th partial output of a real execution 
is defined as REAL (i \k,x;r) = {OUTj : j £ H} U OUTi, 
where H is the set of honest parties and r is all random coins 
of all players. 

Ideal-model execution. In the ideal model, the setup of 
participants is the same except that all parties are inter¬ 
acting with a trusted party that evaluates the function. All 
parties provide inputs x \, auxiliary input Zi, and random 
coins ri. If a party is semi-honest, it provides its actual in¬ 
puts to the trusted party, while if the party is malicious 


or non-colluding, it provides arbitrary input values. In the 
case of the server P 3 , this means simply providing its aux¬ 
iliary input and random coins, as no input is provided to 
the function being evaluated. Once the function is evalu¬ 
ated by the trusted third party, it returns the result to 
the parties Pi and P 2 , while the server P 3 does not re¬ 
ceive the output. If a party aborts early or sends no in¬ 
put, the trusted party immediately aborts. For all honest 
parties, let OUTi be its output to the trusted party, and 
for corrupted parties let OUTi be some value output by Pi. 
The i th partial output of an ideal execution in the pres¬ 
ence of some set of independent simulators is defined as 
IDEAL (i) {k,x;r) = {OUTj : j e H} U OUT where H is 
the set of honest parties and r is all random coins of all 
players. 

Definition 1 . A protocol securely computes a function f 
if there exists a set of probabilistic polynomial-time (PPT) 
simulators {Simi} ie [ 3 ] such that for all PPT adversaries 
(Hi,..., H 3 ), x, z, and for all i G [3], we have 

{REAL (i \k,x-,r)} keN « {IDEAL^(k,x-,r)} keN 
Where S — (Si ,..., S3), Si = Sinii(Ai), and r is random 
and uniform. 

5.3 Security Guarantees 

Generator’s Input Consistency Check 

During the cut-and-choose, multiple copies of the garbled 
circuit are constructed and then either checked or evaluated. 
A malicious generator may provide inconsistent inputs to 
different evaluation circuits. For some functions, it is possible 
to use inconsistent inputs to extract information of Eval’s 
input [29]. 

Claim 1 . The generator in our protocol cannot trick the 
evaluator into using different inputs for different evaluation 
circuits with greater than negligible probability. 

We use the generator’s input consistency check from [38], 
and defer to the proof provided in that paper, noting that 
simulators Si and S2 can be constructed such that any ma¬ 
licious generator (resp. evaluator) cannot tell whether it is 
working with Si (resp. S2) in the ideal model, or with an 
honest evaluator (resp. generator) in the real model. 

We further note there is no problem with allowing the 
cloud to perform this check; for the generator’s inconsistent 
input to pass the check, the cloud would have to see the 
malicious input and ignore it, which would violate the non¬ 
collusion assumption. 

Validity of Evaluator Inputs 

To ensure that the generator cannot learn anything about 
the evaluator’s inputs by corrupting the garbled values sent 
during the OT, we use from CMTB the random input en¬ 
coding technique by Lindell and Pinkas [29]. This technique 
allows the evaluator to encode each input bit as the XOR of a 
set of input bits. Thus, if the generator corrupts one of those 
input bits as in a selective failure attack, it reveals nothing 
about the evaluator’s true input. Additionally, we use the 
commitment technique employed by Kreuter et al. [27] to 
ensure that the generator cannot swap garbled input wire 
labels between the zero and one value. To accomplish this, 
the generator commits to the wire labels before the cut and 
choose. During the cut and choose, the input labels for the 
check circuits are opened to ensure that they correspond to 
only one value across all circuits. Then, during the OOT, 




the commitment keys for the labels that will be evaluated 
are sent instead of the wire labels themselves. Because our 
protocol implements this technique directly from previous 
work, we do not make any additional claims of security. 
Correctness of Saved Values 

Scenarios where either party enters incorrect values in the 
next computation reduce to previously solved problems in 
garbled circuits. If the generator does not use the correct 
values, then it reduces to the problem of creating an incor¬ 
rect garbled circuit. If the evaluator does not use the correct 
saved values then it reduces to the problem of the evaluator 
entering garbage values into the garbled circuit execution; 
this would be caught by the output consistency check. 
Garbled Circuit Generation 

To ensure the evaluated circuits are generated honestly, we 
require two properties. First, we limit the generator’s ability 
to trick the evaluator into evaluating a corrupted circuit 
using a cut-and-choose technique similar to a typical, two- 
party garbled circuit evaluation. Second, we ensure that a 
lazy Cloud attempting to conserve system resources cannot 
bypass the circuit checking step without being discovered. 

Claim 2. Security: Assuming that the hash function UHF(x) 
(as used in phase 3) is a one-way, collision-resistant hash 
and that the commitment scheme used is fully binding, then 
the generator has at best a 2~ k probability of tricking the 
evaluator into evaluating a majority of corrupted circuits, 
where k is the number of circuits generated. 

This claim follows directly from sS13. The probability of 
the generator finding a hash collision and thus fooling the 
evaluator is at most 1/ \B\, where B is the range of the hash 
function. 

Claim 3. Proof-of-work: Assuming the hash function is one¬ 
way and collision resistant, the Cloud has a negligible prob¬ 
ability of producing a check hash that passes the seed check 
without actually generating the check circuit. 

As previously stated, before the circuit check begins the 
generator sends the evaluator k hashed circuit values H\(GCi) 
Once the evaluation circuits are selected, the cloud must 
generate some circuits and hash them into check hashes 
Hi(GCl). If the cloud attempts to skip the generation of 
the check circuits, it must generate hash values H[ — Hi for 
i G Chk. Based on security guarantees of the hash, and the 
non-collusion property, the cloud has a negligible probability 
of correctly generating these hash values. 

Abort on Check Failure 

If any of the check circuits fail, the cloud reports the in¬ 
correct check circuit to both the generator and evaluator. At 
this point, the remaining computation and any saved values 
must be abandoned. However, as is standard in SFE, the 
cloud cannot abort on an incorrect evaluation circuit even 
when it is known to be incorrect. 

Concatenation of Incorrect Circuits 

If the generator produces a single incorrect circuit and the 
cloud does not abort, the generator learns that the circuit 
was used for evaluation, and not as a check circuit. This leaks 
no information about the input or output of the computa¬ 
tion; to do that, the generator must corrupt a majority of 
the evaluation circuits without modifying a check circuit. An 
incorrect circuit that goes undetected in one execution has 
no effect on subsequent executions as long the total amount 
of incorrect circuits is less than the majority of evaluation 
circuits. 


Using Multiple Evaluators 

One of the benefits of our outsourcing scheme is that the 
state is saved at the generator and cloud allowing the use of 
different evaluators in each computation. Previously, it was 
shown a group of users working with a single server using 
2P-SFE was not secure against malicious adversaries, as a 
malicious server and last k parties, also malicious, could re¬ 
play their portion of the computation with different inputs 
and gain more information than they can with a single com¬ 
putation [15]. However, this is not a problem in our system 
as at least one of our servers, either the generator or cloud, 
must be semi-honest due to non-collusion, which obviates 
the attack stated above. 

Threat Model 

As we have many computations involving the same gen¬ 
erator and cloud, we have to extend the threat model for 
how the parties can act in different computations. There can 
be no collusion in each singular computation. However, the 
malicious party can change between computations as long as 
there is no chain of malicious users that link the generator 
and cloud - this would break the non-collusion assumption. 

5.4 Proof 

We formally prove the security of our protocol with the 
following theorem, which gives security guarantees identical 
to that of CMTB and the protocol by Kamara et al. [22]. 

Theorem 1 . The outsourced two-party SFE protocol se¬ 
curely computes a function f(a,b) in the following two cor¬ 
ruption scenarios: (l)The Cloud is malicious and non-cooperative 
with respect to the rest of the parties, while all other parties 
are semi-honest, and (2)All but one party is malicious, while 
the Cloud is semi-honest. 

Proof. To demonstrate that {REAL^\k,x',r)}keN ~ 
{IDEAL^\k, x\ r)}fe G jv, Vi G {generator, evaluator, cloud}, 
we consider separately each case where a party deviates from 
the protocol, and then show that these cases reveal no ad¬ 
ditional information, by considering each point at which the 
parties interact. □ 

For the remaining portion of the proof, we shall call the 
generator, the evaluator, and the cloud, as A, B, and C, 
respectively. To denote that a party is malicious, we shall 
use A*, B*, and C*, respectively. 

5.4.1 Malicious Evaluator 

Both the generator and the cloud participate honestly in 
the protocol. During the protocol execution, the evaluator 
only exchanges messages with the other participants at cer¬ 
tain points: the cut-and-choose, the oblivious transfer, send¬ 
ing decryption information at the end of the OOT, checking 
the generator’s input consistency, and receiving the proof of 
validity and output from the garbled circuit. Thus, our sim¬ 
ulator need only ensure that these sections of the protocol 
are indistinguishable to the adversary - e.g., we need not 
consider phase 4. Our proof comprises the following hybrid 
experiments and lemmas: 

Simulating the random number generation / coin¬ 
flip 

Hybridl^ A \k, x\ r): This experiment is the same as 
REAL^ A \k,x',r) except that instead of running a fair coin 
toss protocol with A*, the experiment chooses a random 





string p, and a coin-flipping simulator S CO inFUp(p , l fc ) pro¬ 
duces the protocol messages that output p. 

Lemma 1. REAL^ A \k, x\r) ~ Hybridl^ A \k, x\ r) 

Proof. Based on the security of the fair coin toss protocol, 
we know that there exists a simulator S CO inFUp (*, •) such 
that an interaction with S CO inFUp(-, •) is indistinguishable 
from a real protocol interaction. Since everything else in 
Hybridl^ A \k, x\ r ) is exactly the same as in REAlS A \k, x; r), 
this proves the lemma. □ 

Simulating the primitive OT 

Hybrid2^ A \k, x\ r): This experiment is the same as 
Hybridl^ (k, x; r ) except that during the Outsourced Obliv¬ 
ious Transfer, the experiment invokes a simulator Sot to 
simulate the primitive oblivious transfer operation with A*. 
The simulator sends A* a random string s and receives the 
columns of the matrix Q*. 

Lemma 2. Hybridl^ (k, x\ r) ~ Hybrids ^ (/c, x\ r ) 

Proof. Based on the malicious security of the OT primitive, 
we know that there exists a simulator Sot such that an in¬ 
teraction with this simulator is indistinguishable from a real 
execution of the oblivious transfer protocol. Since everything 
else in Hybrid2^ A \k, x ; r) is identical to Hybridl^ A \k, x; r), 
this proves the lemma. □ 

Checking the output of OOT 

Hybrid3^ A \k, x\ r): This experiment is the same as 
Hybrid2^ A \k , x\ r) except that the experiment aborts if the 
matrix Q* is not formed correctly (that is, if A* used incon¬ 
sistent input values ea* for any column in generating Q*). 

Lemma 3. Hybrid2^ (k, x\ r) « Hybrid3 ^ (k, x\ r) 

Proof. Let us consider a case in Hybrid2^ A \k,x;r) where 
for some value of i, A* sends the column value T % ® ea! for 
some ea ^ ea * such that the i th bit is b in ea * and b © 1 in 
ea'. Then, for every row in Q*, the i th bit will be encrypted 
in the b ® 1 entry. 

However, when A* sends the value ea* ® p* to the cloud 
for decryption, the cloud will decrypt the i th choice, and 
then it will decrypt the b © 1 entry instead of the b entry. 
This will result in an invalid decryption with probability 
1 — e for a negligible value of e. This decryption is not (with 
high probability) a valid commitment key, so the garbled in¬ 
put values won’t de-commit, causing the cloud to abort. In 
Hybrid3^ A \k,x;r), since the experiment observes the mes¬ 
sages Q* , p* , and ea* ®p* , it can recover ea* and check Q* 
for consistency. (The cloud always aborts if an inconsistency 
is detected.) □ 

Simulating consistency check and substituting in¬ 
puts 

Hybrid4! A \k,x;r): This experiment is the same as 
Hybrid3^ A \k,x;r) except that the experiment provides a 
string of 2 ■ n zeros, denoted 0 2 n , during the consistency 
check to replace the generator’s input. 

Lemma 4. Hybrid3 ^ (k, x\ r) « Hybrids^ (fc, x\ r) 

Proof. Here we cite the proof of shelat and Shen’s scheme [38]. 
Since the messages sent in our scheme are identical to theirs 
in content, we simply change the entity sending the message 
in the experiment and the lemma still holds. □ 


Output and output consistency check 

Hybrid& A \k,x\r) m . This experiment is identical to 
HybridA^ A \k, x\ r) except that instead of returning the out¬ 
put of the circuit, the experiment provides A* with the result 
sent from the trusted external oracle. 

Lemma 5. HybridA^ A \k, x; r) « Hybrid5^ A \k, x ; r) 

Proof. Based on the security of garbled circuits, the trusted 
third party output and the circuit output will be indistin¬ 
guishable when provided with the input of A*, ea*. Since 
we have the k-bit secret key and know the output, we can 
produce the necessary MAC under the one time pad (similar 
to Hybridl). Simulating a majority vote is trivial; the eval¬ 
uator then decrypts the ciphertext using its OTP key, and 
then performs a MAC on the output, and compares with 
the MAC produced within the garbled circuit. This, again, 
is indistinguishable from the circuit version since we know 
the output and can ensure that the MACs are identical. □ 

5.4.2 Malicious Generator 

Here, both the evaluator and the cloud participate hon¬ 
estly in the protocol. 

Simulating the cut and choose Hybridl^ (fc, x\ r): This 

experiment is the same as REAL^ B \k, x;r), except during 
the oblivious transfer (the generator offers up decryption 
keys for his input as well as for the circuit seed and possi¬ 
ble evaluator’s input for each circuit), where we randomly 
choose check and evaluation circuits. 

Lemma 6. REAL^ B \k,x-,r) « Hybridl^ (k, x\ r) 

Proof. Since the generator does not learn the circuit split 
because of the security of the oblivious transfer, this portion 
of the protocol is indistinguishable from the real version. We 
can perform all the checks and decryptions required; we also 
have all the keys needed to check whether we should abort, 
so a selective failure attack does not help distinguish between 
the experiment and the real version. □ 

Simulating the OT Hybrid2^ B \k, x; r): This experiment 
is the same as Hybridl^ B \k, x\ r) except that rather than 
run the primitive oblivious transfer with A, the experiment 
generates a random input string ea and a random matrix T, 
then runs a simulator Sot with B*, which gives B* exactly 
one element from the pair {T l ,T l ® ea) depending on the 
i th selection bit of B*. 

Lemma 7. Hybridl^ B \k, x\ r) ~ Hybrid2^ B \k, x\ r) 

Proof. Based on the security of the primitive OT scheme, we 
know that the simulator Sot exists, that it can recover B*’s 
selection bits from the interaction, and that an interaction 
with it is indistinguishable from a real execution of the OT. 
Since B* cannot learn any distinguishing information from 
A’s input, again based on the security of the OT primitive, 
indistinguishability holds between the two experiments. □ 

Checking the output of OOT Hybrid3^ B \k, x\ r): This 

experiment is the same as E[ybrid2 (yB \k,x\r ) except that 
the experiment checks the validity of B*’s output from the 
OOT. Since the experiment possesses T, ea', and s* (which 
was recovered by the oblivious transfer simulator Sot in the 
previous hybrid), the experiment can check whether or not 
the encrypted set of outputs Y* is well-formed. If not, the 
experiment aborts. 



















Lemma 8. Hybrid2^ B \k, x; r) « Hybrid3^ B \k, x; r) 

Proof. Recall that in Hybrid2^ B \k , x; r), if B* does not for¬ 
mat the output of the OOT correctly, the cloud will fail to 
recover a valid commitment key with probability 1 —e, where 
e is negligible in the security parameter. In this case, the 
committed garbled circuit labels will fail to decrypt properly 
and the cloud will abort the protocol. In Hybrids^ (k, x; r), 
since the experiment has seen the values Q, s*, ea 7 , and Y*, 
it can trivially check to see whether Y* is correctly formed; 
we about on failure, so a selective failure attack does not 
help distinguish between the experiment and the real ver¬ 
sion. Further, B* cannot swap any of A’s input labels in the 
commitments [38]. □ 

Checking input consistency and recovering inputs 

HybridA ^ (fc, x; r ) : This experiment is the same as 
Hybrid?* ^ (k, x; r) except that the experiment recovers B*’s 
input b* during the input consistency check using the ran¬ 
dom seed recovered in HybridC B \k, x ; r). If the consistency 
check does not pass or if B*’s input cannot be recovered, the 
experiment immediately aborts. 

Lemma 9. HybridS^ B \k,x-,r) « HybridA^ B \k, x; r) 

Proof. The experiment can perform a hash of the genera¬ 
tor’s input for each evaluation circuit (we know the split 
from Hybridl). If any of these hashes are different, then we 
know that the generator tried to cheat [38] and can abort if 
necessary - this is done by the cloud in the real version of 
the protocol. □ 

Generating, checking, and evaluating partial input 
gates 

Hybrid5^ B \k, x; r) : This experiment is the same as 
HybridA^ B \k, x; r), except for the following: for check cir¬ 
cuits, the experiment uses the data sent by the generator, 
as well as POutOij , POutlij, and CSeedi (recovered dur¬ 
ing the cut-and-choose) to generate the partial input gates 
in the same manner as shown in phase 4. It then compares 
these gates to those the generator sent. If any gate does not 
match, we know the generator tried to cheat. For evaluation 
circuits, it finds the point and permute bit and produces the 
value GInxij (this is needed for future hybrids). 

Lemma 10. Hybrid4^ B \k, x; r) « Hybrid5^ B \k, x; r) 

Proof. The experiment already has all the POut values from 
previous hybrids, and receives 

Ri, TTOij, TTlij, and bit location ( setPPBitGen ) from 
B*. It also has CSeedi from Hybridl - thus, it can generate 
the partial input gates as described in phase 4, and perform 
all the necessary checks. Since we also know the split from 
Hybridl, we can also generate GInxij values for the evalua¬ 
tion circuits (which are then entered into the garbled circuit 
by the cloud in the real version of the protocol). □ 

Simulating the output check Hybrid6^ B \k, x;r): This 
experiment is the same as Hybrid5^ B \k, x;r) except that 
during the output phase the experiment prepares the result 
received from the trusted third party as the output instead 
of the output from the circuit. 

Lemma 11. Hybrids^ (k, x; r) « Hybrid^ ^ (fc, x; r) 


Proof. Based on the security of garbled circuits, the trusted 
third party output and the circuit output will be indistin¬ 
guishable when provided with the input of B*, b*. Since we 
have the k-bit secret key and know the output, we can pro¬ 
duce the necessary MAC under the one time pad (similar to 
Hybridl). Simulating a majority vote is trivial; the experi¬ 
ment then decrypts the ciphertext using its OTP key, and 
then performs a MAC on the output, and compares with 
the MAC produced within the garbled circuit. This, again, 
is indistinguishable from the circuit version to B*, since we 
know the appropriate OTP key. □ 

5.4.3 Malicious Cloud 

Here, both the generator and the evaluator participate 
honestly in the protocol. 

Replacing inputs for the OOT Hybridl^ (k, x; r): This 

experiment is the same as REAL^ (k, x; r) except that dur¬ 
ing the OOT, the experiment replaces A’s input ea with a 
string of zeros ea' — 0 2 ' l ' n . This value is then used to select 
garbled input values from B in the OOT, which are then 
forwarded to C* according to the protocol. 

Lemma 12. REAL^ c \k,x;r) « Hybridl^ c \k, x; r) 

Proof. In a real execution, C* will observe the random ma¬ 
trix T, the encrypted commitment keys Y, and A’s input 
XOR’d with the permutation string ea ® p. Since p is ran¬ 
dom, ea®p is indistinguishable from p. Since T is randomly 
generated in both REAL^ c \k, x; r) and HybridC c \k , x; r), 
they are trivially indistinguishable. Considering the output 
pairs Y, half of the commitment keys (those not selected by 
A) will consist of values computationally indistinguishable 
from random (since they are XOR’d with a hash), and the 
keys can only be recovered if C* can find a collision with the 
hash value H(j, s ) without having B’s random value s. Thus, 
C* cannot distinguish an execution of OOT with A’s input 
ea and the simulator’s input replacement ea'. Since the rest 
of the protocol follows REAL^ c \k, x; r) exactly, this proves 
the lemma. □ 

Replacing inputs for the consistency check 

Hybrid2^ c \k, x; r) : This experiment is the same as 
HybridC c \k, x\ r) except that the experiment replaces B’s 
input b with all zeros 0 2 n . This value is then prepared and 
checked according to the protocol for consistency across eval¬ 
uation circuits. 

Lemma 13. HybridC c \k, x; r) « Hybrid2^ c \k,x\r) 

Proof. In this hybrid, C* observes a set of garbled input wire 
values from B. Based on the security of garbled circuits, ob¬ 
serving one set of garbled input wire values is indistinguish¬ 
able from observing any other set of input wire values, such 
that C* cannot distinguish between the garbled input for b 
and the garbled input for 0 2 n . The rest of the hybrid is the 
same as HybridC c \k, x; r). □ 

Partial gates HybridS^ c \k, x;r): This experiment is the 
same as Hybrid2 <yC ^ > (k, x; r) except that the experiment sends 
the appropriate truth table information, Ri , POut values, 
and the bit location from setPPBitGen to C*. 

Lemma 14. Hybrid2^ c \k, x;r) « HybridS^ c \k^x\r) 


















Proof. In this hybrid, C* observes a set of garbled wire and 
truth table values from B. Since these partial gates are iden¬ 
tical to garbled circuit gates as far as operation is concerned, 
the security of garbled circuits ensures that observing one 
set of garbled input wire values is indistinguishable from 
observing any other set of wire values, such that C* cannot 
distinguish between the garbled value for b and the gar¬ 
bled value for 0 2 n . The rest of the hybrid is the same as 
Hybrid *!^ (k,x;r). □ 

Checking the output 

Hybrid4^ c \k, x;r): This experiment is the same as 
Hybrids^ (k, x\ r) except that after the circuit is evaluated, 
the experiment checks that the result output by C* is as 
expected; otherwise, the experiment immediately aborts. 

Lemma 15. Hybrid3^ c \k,x]r) « Hybrid4^ c \k,x\r) 

Proof. After the cloud sends the output (under the OTP 
from phase 1) to us, we can decrypt, since we have the OTP 
from previous hybrids. We then perform a MAC and com¬ 
pare with the MAC calculated within the garbled circuit to 
verify that C* did not modify the output. □ 

6. PERFORMANCE EVALUATION 

We now demonstrate the efficacy of PartialGC through 
a comparison with the CMTB outsourcing system. Apart 
from the performance gains from using cut-and-choose from 
sS13, PartialGC provides other benefits through generating 
partial input values after the first execution of a program. 
On subsequent executions, the partial inputs act to amortize 
overall costs of execution and bandwidth. 

We demonstrate that the evaluator in the system can be a 
mobile device outsourcing computation to a more powerful 
system. We also show that other devices, such as server- 
class machines, can act as evaluators, to show the generality 
of this system. Our testing environment includes a 64-core 
server containing 1 TB of RAM, which we use to model 
both the Generator and Outsourcing Proxy parties. We run 
separate programs for the Generator and Outsourcing Proxy, 
giving them each 32 threads. For the evaluator, we use a 
Samsung Galaxy Nexus phone with a 1.2 GHz dual-core 
ARM Cortex-A9 and 1 GB of RAM running Android 4.0, 
connected to the server through an 802.11 54 Mbps WiFi in 
an isolated environment. In our testing we also use a single 
server process as the evaluator. For these tests we create that 
process on our 64-core server as well. We ran the CMTB 
implementation for comparison tests under the same setup. 

6.1 Execution Time 

The PartialGC system is particularly well suited to com¬ 
plex computations that require multiple stages and the sav¬ 
ing of intermediate state. Previous garbled circuit execution 
systems have focused on single-transaction evaluations, such 
as computing the “millionaires” problem (i.e., a joint evalua¬ 
tion of which party inputs a greater value without revealing 
the values of the inputs) or evaluating an AES circuit. 

Our evaluation considers two comparisons: the improve¬ 
ment of our system compared with CMTB without reusing 
saved values, and comparing our protocol for saving and 
reusing values against CMTB if such reuse was implemented 
in that protocol. We also benchmark the overhead for sav¬ 
ing and loading values on a per-bit basis for 256 circuits, a 


necessary number to achieve a security parameter of 2 -80 
in the malicious model. In all cases, we run 10 iterations of 
each test and give timing results with 95% confidence inter¬ 
vals. Other than varying the number of circuits our system 
parameters are set for 80-bit security. 

The programs used for our evaluation are exemplars of 
differing input sizes and differing circuit complexities: 

Keyed Database: In this program, one party enters a database 
and keys to it while the other party enters a key that indexes 
into the database, receiving a database entry for that key. 
This is an example of a program expressed as a small circuit 
that has a very large amount of input. 

Matrix Multiplication: Here, both parties enter 32-bit 
numbers to fill a matrix. Matrix multiplication is performed 
before the resulting matrix is output to both parties. This 
is an example of a program with a large amount of inputs 
with a large circuit. 

Edit (Levenstein) Distance: This program finds the dis¬ 
tance between two strings of the same length and returns 
the difference. This is an example of a program with a small 
number of inputs and a medium sized circuit. 

Millionaires: In this classic SFE program, both parties en¬ 
ter a value, and the result is a one-bit output to each party 
to let them know whether their value is greater or smaller 
than that of the other party. This is an example of a small 
circuit with a large amount of input. 

Gate counts for each of our programs can be found in Ta¬ 
ble 1. The only difference for the programs described above 
is the additional of a MAC function in PartialGC. We dis¬ 
cuss the reason for this check in Section 6.4. 

Table 2 shows the results from our experimental tests. In 
the best case, execution time was reduced by a factor of 
32 over CMTB, from 1200 seconds to 38 seconds, a 96% 
speedup over CMTB. Ultimately, our results show that our 
system outperforms CMTB when the input checks are the 
bottleneck. This run-time improvement is due to improve¬ 
ments we added from sS13 and occurs in the keyed database, 
millionaires, and matrix multiplications programs. In the 
other program, edit distance, the input checks are not the 
bottleneck and PartialGC does not outperform CMTB. The 
total run-time increase for the edit distance problem is due 
to overhead of using the new sS13 OT cut-and-choose tech¬ 
nique which requires sending each gate to the evaluator for 
check circuits and evaluation circuits. This is discussed fur¬ 
ther in Section 6.4. The typical use case we imagine for our 
system, however, is more like the keyed database program, 
which has a large amount of inputs and a very small circuit. 

We expand upon this use case later in this section. 

Reusing Values 

For a test of our system’s wire saving capabilities we tested 
a dynamic programming problem, longest common substring, 
in both PartialGC and CMTB. This program determines 
the length of the longest common substring between two 
strings. Rather than use a single computation for the solu¬ 
tion, our version incrementally adds a single bit of input to 
both strings each time the computation is run and outputs 
the results each time to the evaluator. We believe this is 
a realistic comparison to a real-world application that in¬ 
crementally adds data during each computation where it is 
faster to save the intermediate state and add to it after see¬ 
ing an intermediate result than rerun the entire computation 
many times after seeing the result. 

For our testing, PartialGC uses our technique to reuse 





CMTB 

PartialGC 

KeyedDB 64 

6,080 

20,891 

KeyedDB 128 

12,160 

26,971 

KeyedDB 256 

24,320 

39,131 

MatrixMult8x8 

3,060,802 

3,305,113 

Edit Distance 128 

1,434,888 

1,464,490 

Millionaires 8192 

49,153 

78,775 

LCS Incremental 128 

4,053,870 

87,236 

LCS Incremental 256 

8,077,676 

160,322 

LCS Incremental 512 

16,125,291 

306,368 

LCS Full 128 

2,978,854 

- 

LCS Full 256 

13,177,739 

- 


Table 1: Non-XOR gate counts for the various circuits. In the first 6 circuits, the difference between CMTB and PartialGC 
gate counts is in the consistency checks. The explanation for the difference in size between the incremental versions of longest 
common substring (LCS) is given in Reusing Values. 



16 Circuits 

64 Circuits 

256 Circuits 


CMTB 

PartialGC 


CMTB 

PartialGC 


CMTB 

PartialGC 


KeyedDB 64 

18 ± 2% 

3.5 ± 3% 

5.lx 

72 ± 2% 

8.3 ± 5% 

8.7x 

290 ± 2% 

26 ± 2% 

1 lx 

KeyedDB 128 

33 ± 2% 

4.4 ± 8% 

7.5x 

140 ± 2% 

9.5 ± 4% 

15x 

580 ± 2% 

31 ± 3% 

19x 

KeyedDB 256 

65 ± 2% 

4.6 ± 2% 

14x 

270 ± 1% 

12 ± 6% 

23x 

1200 ± 3% 

38 ± 5% 

32x 

MatrixMult8x8 

48 ± 4% 

46 ± 4% 

l.Ox 

110 ± 8% 

100 ± 7% 

1. lx 

400 ± 10% 

370 ± 5% 

1. lx 

Edit Distance 128 

21 ± 6% 

22 ± 3% 

0.95x 

47 ± 7% 

50 ± 9% 

0.94x 

120 ± 9% 

180 ± 6% 

0.67x 

Millionaires 8192 

35 ± 3% 

7.3 ± 6% 

4.8x 

140 ± 2% 

20 ± 2% 

7.Ox 

580 ± 1% 

70 ± 2% 

8.3x 


Table 2: Timing results comparing PartialGC to CMTB without saving any values. All times in seconds. 



LargestSubstring128 LargestSubstring256 LargestSubstring512 
Program 


Figure 4: Results from testing our largest common substring 
(LCS) programs for PartialGC and CMTB. This shows 
when changing a single input value is more efficient un¬ 
der PartialGC than either CMTB program. CMTB crashed 
on running LCS Incremental of size 512 due to memory re¬ 
quirements. We were unable to complete the compilation of 
CMTB Full of size 512. 


wire values. In CMTB, we save each desired internal bit 
under a one-time pad and re-enter them into the next com¬ 
putation, as well as the information needed to decrypt the 
ciphertext. We use a MAC (the AES circuit of KSS12) to 
verify that the party saving the output bits did not modify 
them. We also use AES to generate a one-time pad inside 
the garbled circuit. We use AES as this is the only cryp¬ 
tographically secure function used in CMTB. Both parties 
enter private keys to the MAC functions. This program is 
labeled CMTB-Inc , for CMTB incremental The size of this 
program represents the size of the total strings. We also cre¬ 
ated a circuit that computes the complete longest common 
substring in one computation labeled CMTB-Full. 


The resulting size of the PartialGC and CMTB circuits 
are shown in Table 1, and the results are shown in Figure 4. 
This result shows that saving and reusing values in Par¬ 
tialGC is more efficient than completely rerunning the com¬ 
putation. The input consistency check adds considerably to 
the memory use on the phone for CMTB-Inc and in the case 
of input bit 512, the CMTB-Inc program will not complete. 
In the case of the 512-bit CMTB-Full , the program would 
not complete compilation in over 42 hours. In our CMTB- 
Inc program, we assume the cloud saves the output bits so 
that multiple phones can have a shared private key. 

Note that the growth of CMTB-Inc and CMTB-Full are 
different. CMTB-Full grows at a larger rate (4x for each 
2x factor increase) than CMTB-Inc (2x for each 2x factor 
increase), implying that although at first it seems more ef¬ 
ficient to rerun the program if small changes are desired in 
the input, eventually this will not be the case. Even with a 
more efficient AES function, CMTB-Inc would not be faster 
as the bottleneck is the input, not the size of the circuit. 

The overhead of saving and reusing values is discussed 
further in Appendix B. 

Outsourcing to a Server Process 

PartialGC can be used in other scenarios than just out¬ 
sourcing to a mobile device. It can outsource garbled circuit 
evaluation from a single server process and retain perfor¬ 
mance benefits over a single server process of CMTB. For 
this experiment the outsourcing party has a single thread. 
Table 3 displays these results and shows that in the KeyedDB 
256 program, PartialGC has a 92% speedup over CMTB. 
As with the outsourced mobile case, keyed database prob¬ 
lems perform particularly well in PartialGC. Because the 
computationally-intensive input consistency check is a greater 
bottleneck on mobile devices than servers, these improve¬ 
ments for most programs are less dramatic. In particular, 
both edit distance and matrix multiplication programs ben¬ 
efit from higher computational power and their bottlenecks 




























































16 Circuits 

64 Circuits 

256 Circuits 


CMTB 

PartialGC 


CMTB 

PartialGC 


CMTB 

PartialGC 


KeyedDB 64 

6.6 ± 4% 

1.4 ± 1% 

4.7x 

27 ± 4% 

5.1 ± 2% 

5.3x 

110 ± 2 % 

24.9 ± 0.3% 

4.4x 

KeyedDB 128 

13 ± 3% 

1.8 ± 2 % 

7.2x 

54 ± 4% 

5.8 ± 2% 

9.3x 

220 ± 5% 

27.9 ± 0.5% 

7.9x 

KeyedDB 256 

25 ± 4% 

2.5 ± 1% 

lOx 

110 ± 7% 

7.3 ± 2 % 

15x 

420 ± 4% 

33.5 ± 0.6% 

13x 

MatrixMult 8 x 8 

42 ± 3% 

41 ± 4% 

l.Ox 

94 ± 4% 

79 ± 3% 

1 . 2 x 

300 ± 10% 

310 ± 1% 

0.97x 

Edit Distance 128 

18 ± 3% 

18 ± 3% 

l.Ox 

40 ± 8 % 

40 ± 6 % 

l.Ox 

120 ± 9% 

150 ± 3% 

0 . 8 x 

Millionaires 8192 

13 ± 4% 

3.2 ± 1% 

4.lx 

52 ± 3% 

8.5 ± 2% 

6 .lx 

220 ± 5% 

38.4 ± 0.9% 

5.7x 


Table 3: Timing results from outsourcing the garbled circuit evaluation from a single server process. Results in seconds. 



256 Circuits 


CMTB 

PartialGC 


KeyedDB 64 

64992308 

3590416 

18x 

KeyedDB 128 

129744948 

3590416 

36x 

KeyedDB 256 

259250228 

3590416 

72x 

MatrixMult8x8 

71238860 

35027980 

2.Ox 

Edit Distance 128 

2615651 

4108045 

0.64x 

Millionaires 8192 

155377267 

67071757 

2.3x 


Table 4: Bandwidth comparison of CMTB and PartialGC. 
Bandwidth counted by instrumenting PartialGC to count 
the bytes it was sending and receiving and then adding them 
together. Results in bytes. 


on a server are no longer input consistency; as a result, they 
execute faster in CMTB than in PartialGC. 

6.2 Bandwidth 

Since the main reason for outsourcing a computation is 
to save on resources, we give results showing a decrease in 
the evaluator’s bandwidth. Bandwidth is counted by making 
the evaluator to count the number of bytes PartialGC sends 
and receives to either server. Our best result gives a 98% 
reduction in bandwidth (see Table 4). For the edit distance, 
the extra bandwidth used in the outsourced oblivious trans¬ 
fer for all circuits, instead of only the evaluation circuits, 
exceeds any benefit we would otherwise have received. 

6.3 Secure Friend Finder 

Many privacy-preserving applications can benefit from us¬ 
ing PartialGC to cache values for state. As a case study, 
we developed a privacy-preserving friend finder application, 
where users can locate nearby friends without any user di¬ 
vulging their exact location. In this application, many differ¬ 
ent mobile phone clients use a consistent generator (a server 
application) and outsource computation to a cloud. The gen¬ 
erator must be the same for all computations; the cloud must 
be the same for each computation. The cloud and generator 
are two different parties. After each computation, the map 
is updated when PartialGC saves the current state of the 
map as wire labels. Without PartialGC outsourcing values 
to the cloud, the wire labels would have to be transferred 
directly between mobile devices, making a multi-user appli¬ 
cation difficult or impossible. 

We define three privacy-preserving operations that com¬ 
prise the application’s functionality: 

MapStart - The three parties (generator, evaluator, cloud) 
create a “blank” map region, where all locations in the map 
are blank and remain that way until some mobile party sets 
a location to his or her ID. 

MapSet - The mobile party sets a single map cell to a 
new value. This program takes in partial values from the 



MapStart MapSet MapGet 

Program 

Figure 5: Run time comparison of our map programs with 
two different map sizes. 


generator and cloud and outputs a location selected by the 
mobile party. 

MapGet - The mobile party retrieves the contents of a sin¬ 
gle map cell. This program retrieves partial values from the 
generator and cloud and outputs any ID set for that cell to 
the mobile. 

In the application, each user using the Secure Friend Finder 
has a unique ID that represents them on the map. We divide 
the map into “cells”, where each cell is a set amount of area. 
When the user presses “Set New Location,” the program will 
first look to determine if that cell is occupied. If the cell is 
occupied, the user is informed he is near a friend. Otherwise 
the cell is updated to contain his user ID and remove his ID 
from his previous location. We assume a maximum of 255 
friends in our application since each cell in the map is 8 bits. 

Figure 5 shows the performance of these programs in the 
malicious model with a 2“ 80 security parameter (evaluated 
over 256 circuits). We consider map regions containing both 
256 and 2048 cells. For maps of 256 cells, each operation 
takes about 30 seconds. 1 As there are three operations for 
each “Set New Location” event, the total execution time is 
about 90 seconds, while execution time for 2048 cells is about 
3 minutes. The bottleneck of the 64 and 256 cell maps is the 
outsourced oblivious transfer, which is not affected by the 
number of cells in the map. The vastly larger circuit associ¬ 
ated with the 2048-cell map makes getting and setting values 
slower operations, but these results show such an application 
is practical for many scenarios. 

Example - As an example, two friends initiate a friend 
finder computation using Amazon as the cloud and Face- 
book as the generator. The first friend goes out for a coffee 
at a cafe. The second friend, riding his bike, gets a message 

1 Our 64-cell map, as seen in figure 5, also takes about 30 
seconds for each operation. 




















































(a) Location selected. (b) After computation. 

Figure 6: Screenshots from our application, (a) shows the 
map with radio buttons a user can select to indicate position, 
(b) show the result after “set new position” is pressed when 
a user is present. The application is set to use 64 different 
map locations. Map image from Google Maps. 


that his friend is nearby and looks for a few minutes and 
finds him in the cafe. Using this application prevents either 
Amazon or Facebook from knowing either user’s location 
while they are able to learn whether they are nearby. 

6.4 Discussion 

Analysis of improvements 

We analyzed our results and found the improvements came 
from three places: the improved sS13 consistency check, the 
saving and reusing of values, and the fixed oblivious trans¬ 
fer. In the case of the sS13 consistency check, there are two 
reasons for the improvement: first, there is less network traf¬ 
fic, and second, it uses symmetric key operations instead of 
exponentiations. In the case of saving and reusing values, 
we save time with the faster input consistency check and by 
not requiring a user to recompute a circuit multiple times. 
Lastly, we reduced the runtime and bandwidth by fixing 
parts of the OOT. The previous outsourced oblivious trans¬ 
fer performed the primitive OT S (S being the number of 
circuits) times instead of a single time, which turn forced 
many extra exponentiations. Each amount of improvement 
varies depending upon the circuit. 

Output check 

Although the garbled circuit is larger for our output check, 
this check performs less cryptographic operations for the 
outsourcing party, as the evaluator only has to perform a 
MAC on the output of the garbled circuit. We use this check 
to demonstrate using a MAC can be an efficient output check 
for a low power device when the computational power is not 
equivalent across all parties. 

Commit Cut-and-Choose vs OT Cut-and-Choose 

Our results unexpectedly showed that the sS13 OT cut- 
and-choose used in PartialGC is actually slower than the 
KSS12 commit cut-and-choose used in CMTB in our ex¬ 
perimental setup. Theoretically, sS13, which requires fewer 


cryptographic operations, as it generates the garbled circuit 
only once, should be the faster protocol. The difference be¬ 
tween the two cut-and-choose protocols is the network usage 
- instead of | of the circuits (CMTB), all the circuits must 
be transmitted in sS13. The sS13 cut-and-choose is required 
in our protocol so that the cloud can check that the gener¬ 
ator creates the correct gates. 

6.5 Implementation Optimizations 

We proceeded to optimize our system in light of the slow¬ 
down we saw when compared to CMTB for circuits with 
large amounts of gates. We made the following changes: (1) 
turn AES-NI on, as it was not turned on by default in CMTB 
(or [27], which CMTB is based on), (2) hand-optimize the 
garbled gate generation and evaluation to remove excess 
memory operations, (3) remove the need for network I/O for 
XOR gates from the underlying implementation (previously, 

4 bytes were spuriously transmitted for each XOR gate), (4) 
batch process gates to reduce the overhead of networking 
for each gate, and (5) remove unnecessary hash calls that 
existed in PartialGC as an artifact of being built on CMTB. 

6.6 Corrections of Underlying Implementation 

We made two corrections to the implementation of Par¬ 
tialGC that are artifacts of the underlying implementations. 
The first error was from KSS and while the other was from 
CMTB. We performed the following changes: (1) further cor¬ 
rect the OT phase of CMTB and (2) add a missing input 
encoding phase that was supposed to exist in KSS. The first 
error was straightforward: rather than performing a single 
set of OTs and then extending it to all circuits, after the 
single set of OTs in CMTB, a matrix transformation was 
performed for each circuit (instead of a single matrix trans¬ 
formation). We removed this error and added the necessary 
correction, i.e. after the single set of OTs were performed, 
the results from the OTs were extended in the same manner 
as in our protocol description. To correct the second error, 
we added the missing input encoding step for the evalua¬ 
tor’s input. Note that KSS and all subsequent systems built 
from it do not have this input encoding. Without the input 
encoding, a selective failure attack can be performed easily 
by the generator in order to gain information about a single 
bit of the evaluator‘s input. 

6.7 Results from Correct and More Optimal 
Implementation 

In Table 5 we present results from the corrected and more 
optimal implementation of PartialGC. We observe the fol¬ 
lowing: 

1. The program that has a large evaluator’s input and very 
little gates is slightly slower due to the fixed OT error 
and added input encoding (Millionaires). 

2. The program with a large circuit size when compared 
with the input sizes of both the generator and evaluator 
has improved runtime performance (Edit distance). 

3. The program we tested that has high input and also has 
a high gate count is improved (Matrix Mult). 

4. The program that relies mostly on the generator’s input 
size with a low amount of gates is largely unaffected by 
the OT change or the added input encoding but is still 
improved by the optimizations to the garbled gate run¬ 
time (Keyed DB). 










16 Circuits 

64 Circuits 

256 Circuits 


Imp 


Orig. 


Imp. 

Orig. 


Imp. 

Orig. 


KeyedDB 64 

4 

± 10 % 

3.5 ± 3% 

0.92x 

4.4 

± 

5% 

8.3 

± 

5% 

1.9x 

7.6 

± 

6 % 

26 

± 

2 % 

3.4x 

KeyedDB 128 

3.8 

± 10 % 

4.4 ± 8 % 

1 . lx 

4.5 

± 

8 % 

9.5 

± 

4% 

2 .lx 

8.1 

± 

4% 

31 

± 

3% 

3.8x 

KeyedDB 256 

4.0 

± 

4% 

4.6 ± 2% 

1 . lx 

4.7 

± 

9% 

12 

± 

6 % 

2.7x 

9.3 

± 

4% 

38 

± 

5% 

4.Ox 

MatrixMult 8 x 8 

21 

± 

2 % 

46 ± 4% 

2 . 2 x 

29 

± 

4% 

100 

± 

7% 

3.5x 

69 

± 

2 % 

370 

± 

5% 

5.4x 

EditDist 128 

7.8 

± 

4% 

22 ± 3% 

2 . 8 x 

10 

±~ 

4% 

50 

~± 

9% 

4.8x 

21 

~± 

2 % 

180 

~± 

6 % 

8.9x 

Millionaires 8192 

24 

± 

5% 

7.3 ± 6 % 

0.30x 

30 

T 

3% 

20 

~± 

2 % 

0 . 68 x 

78 

~± 

3% 

70 

~± 

2% 

0.89x 


Table 5: Comparing the original PartialGC and the improved version of PartialGC. Results in seconds. 


6.8 SFE Engineering Insights 

Given our experience from building on other frameworks, 
we provide our insights: 

1. If runtime results do not describe the intuition of the pro¬ 
tocol then there is most likely something incorrect in the 
implementation. For instance, if the average time to eval¬ 
uate garbled gates is greater than the average time to gen¬ 
erate the garbled gates there is most likely a problem in 
the garbled circuit evaluation phase. 

2. Although comparing the time of garbling and evaluating 
can be interesting in its own right, evaluating the total 
time of full garbled circuit garbling and evaluation (in¬ 
cluding network overhead) is also insightful as networking 
and related operations can be the bottleneck in a practi¬ 
cal system. This includes network usage, the effects of a 
cut-and-choose protocol, and the time it takes to get the 
next gate from the interpreter or circuit file. 

3. When using another implementation, check to verify each 
protocol step exists in the implementation. 

4. Implementing checks at the circuit layer that are exposed 
to an end-user is not worth the time saved by not encoding 
them directly into the garbled circuit. This comes from our 
experience with our output consistency check, which was 
difficult to create correctly for each test program. 

5. Ensure that all the features of a developed compiler and 
execution system are thoroughly unit tested. 

7. RELATED WORK 

SFE was first described by Yao in his seminal paper [39] 
on the subject. The first general purpose platform for SFE, 
Fairplay [32], was created in 2004. Fairplay had both a com¬ 
piler for creating garbled circuits, and a run-time system for 
executing them. Computations involving three or more par¬ 
ties have also been examined; one of the earliest examples 
is FairplayMP [2]. There have been multiple other imple¬ 
mentations since, in both semi-honest [6, 9, 16, 17, 40] and 
malicious settings [26, 37]. 

Optimizations for garbled circuits include the free-XOR 
technique [25], garbled row reduction [36], rewriting compu¬ 
tations to minimize SFE [23], and pipelining [18]. Pipelining 
allows the evaluator to proceed with the computation while 
the generator is creating gates. 

Kreuter et al. [27] included both an optimizing compiler 
and an efficient run-time system using a parallelized imple¬ 
mentation of SFE in the malicious model from [37]. 

The creation of circuits for SFE in a fast and efficient man¬ 
ner is one of the central problems in the area. Previous com¬ 
pilers, from Fairplay to KSS12, were based on the concept of 
creating a complete circuit and then optimizing it. PAL [33] 
improved such systems by using a simple template circuit, 
reducing memory usage by orders of magnitude. PCF [26] 


built from this and used a more advanced representation to 
reduce the disk space used. 

Other methods for performing MPC involve homomorphic 
encryption [3, 12], secret sharing [4], and ordered binary 
decision diagrams [28]. A general privacy-preserving com¬ 
putation protocol that uses homomorphic encryption and 
was designed specifically for mobile devices can be found 
in [7]. There are also custom protocols designed for partic¬ 
ular privacy-preserving computations; for example, Kamara 
et al. [21] showed how to scale server-aided Private Set In¬ 
tersection to billion-element sets with a custom protocol. 

Previous reusable garbled-circuit schemes include that of 
Brandao [5], which uses homomorphic encryption, Gentry 
et al. [10], which uses attribute-based functional encryption, 
and Goldwasser et al. [13], which introduces a succinct func¬ 
tional encryption scheme. These previous works are purely 
theoretical; none of them provides experimental performance 
analysis. There is also recent theoretical work on reusing 
encrypted garbled-circuit values [30, 11, 31] in the ORAM 
model; it uses a variety of techniques, including garbled cir¬ 
cuits and identity-based encryption, to execute the underly¬ 
ing low-level operations (program state, read/write queries, 
etc.). Our scheme for reusing encrypted values is based on 
completely different techniques; it enables us to do new kinds 
of computations, thus expanding the set of things that can 
be computed using garbled circuits. 

The Quid-Pro-Quo-tocols system [19] allows fast execu¬ 
tion with a single bit of leakage. The garbled circuit is ex¬ 
ecuted twice, with the parties switching roles in the latter 
execution, then running a secure protocol to ensure that the 
output from both executions are equivalent; if this fails, a 
single bit may be leaked due to the selective failure attack. 

8. CONCLUSION 

This paper presents PartialGC, a server-aided SFE scheme 
allowing the reuse of encrypted values to save the costs of in¬ 
put validation and to allow for the saving of state, such that 
the costs of multiple computations may be amortized. Com¬ 
pared to the server-aided outsourcing scheme by CMTB, we 
reduce costs of computation by up to 96% and bandwidth 
costs by up to 98%. Future work will consider the general¬ 
ity of the encryption re-use scheme to other SFE evaluation 
systems and large-scale systems problems that benefit from 
the addition of state, which can open up new and intriguing 
ways of bringing SFE into the practical realm. 
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APPENDIX 

A. CMTB PROTOCOL 

As we are building off of the CMTB garbled circuit exe¬ 
cution system, we give an abbreviated version of the proto¬ 
col. In our description we refer to the generator, the cloud, 
and the evaluator. The cloud is the party the evaluator out¬ 
sources her computation to. 

Circuit generation and check: The template for the gar¬ 
bled circuit is augmented to add one-time XOR pads on the 
output bits and split the evaluator’s input wires per the in¬ 
put encoding scheme. The generator generates the necessary 
garbled circuits and commits to them and sends the com¬ 
mitments to the evaluator. The generator then commits to 
input labels for the evaluator’s inputs. 

CMTB relies on Goyal et al.’s [14] random seed check, 
which was implemented by Kreuter et al. [27] to combat 
generation of incorrect circuits. This technique uses a cut- 
and-choose style protocol to determine whether the genera¬ 
tor created the correct circuits by creating and committing 
to many different circuits. Some of those circuits are used 
for evaluation, while the others are used as check circuits. 

Evaluator’s inputs: Rather than a two-party oblivious 
transfer, we perform a three-party outsourced oblivious trans¬ 
fer. An outsourced oblivious transfer is an OT that gets the 
select bits from one party, the wire labels from another, and 
returns the selected wire labels to a third party. The party 
that selects the wire labels does not learn what the wire la¬ 
bels are, and the party that inputs the wire labels does not 
learn which wire was selected; the third party only learns 
the selected wire labels. In CMTB, the generator offers up 
wire labels, the evaluator provides the select bits, and the 
cloud receives the selected labels. CMTB uses the Ishai OT 
extension [20] to reduce the number of OTs. 

CMTB uses an encoding technique from Lindell and Pinkas 
[29], which prevents the generator from finding out any in¬ 
formation about the evaluator’s input if a selective failure 
attack transpires. CMTB also uses the commitment tech¬ 
nique of Kreuter et al. [27] to prevent the generator from 
swapping the two possible outputs of the oblivious transfer. 
To ensure the evaluator’s input is consistent across all cir¬ 
cuits, CMTB uses a technique from Lindell and Pinkas [29], 
whereby the inputs are derived from a single oblivious trans¬ 
fer. 

Generator’s input and consistency check: The gener¬ 
ator sends his input to the cloud for the evaluation circuits. 
Then the generator, evaluator, and cloud all work together 
to prove the input consistency of the generator’s input. For 
the generator’s input consistency check, CMTB uses the 
malleable-claw free construction from shelat and Shen [37]. 



Program 

Figure 7: The amount of time it takes to save and load a bit 
in PartialGC when using 256 circuits. 

Circuit evaluations: The cloud evaluates the garbled cir¬ 
cuits marked for evaluation and checks the circuits marked 
for checking. The cloud enters in the generator and eval¬ 
uator’s input into each garbled circuit and evaluates each 
circuit. The output for any particular bit is then the ma¬ 
jority output between all evaluator circuits. The cloud then 
recreates each check circuit. The cloud creates the hashes of 
each garbled circuit and sends those hashes to the evaluator. 
The evaluator then verifies the hashes are the same as the 
ones the generator previously committed to. 

Output consistency check and output: The three par¬ 
ties prove together that the cloud did not modify the output 
before she sent it to the generator or evaluator. Both the 
evaluator and generator receive their respective outputs. All 
outputs are blinded by the respective party’s one-time pad 
inside the garbled circuit to prevent the cloud from learning 
what any output bit represents. 

CMTB uses the XOR one-time pad technique from Ki- 
raz [24] to prevent the evaluator from learning the gener¬ 
ator’s real output. To prevent output modification, CMTB 
uses the witness-indistinguishable zero-knowledge proof from 
Kreuter et al. [27]. 

B. OVERHEAD OF REUSING VALUES 

We created several versions of the keyed database program 
to determine the runtime of saving and loading the database 
on a per bit basis using our system (See Figure 7). This 
figure shows it is possible to save and load a large amount 
of saved wire labels in a relatively short time. The time to 
load a wire label is larger than the time to save a value since 
saving only involves saving the wire label to a file and loading 
involves reading from a file and creating the partial input 
gates. Although not shown in the figure, the time to save or 
load a single bit also increases with the circuit parameter. 
This is because we need S copies of that bit - one for every 
circuit. 

C. EXAMPLE PROGRAM 

In this section we describe the execution of an attendance 
application. Consider a scenario where the host wants each 
user to sign in from their phones to keep a log of the guests, 
but also wants to keep this information secret. 

This application has three distinct programs. The first 
program initializes a counter to a number input by the eval- 























uator. The second program, which is used until the last pro¬ 
gram is called, takes in a name and increments the counter 
by one. The last program outputs all names and returns the 
count of users. For this application, users (specifically, their 
mobile phones) assume the role of evaluators in the protocol 
(Section 4). 

First, the host runs the initial program to initialize a 
database. We cannot execute the second program to add 
names to the log until this is done, lest we reveal that there 
is no memory saved (z.e., there is no one else present). 
Protocol in Brief: In this first program, the cut-and-choose 
OT is executed to select the circuit split (the circuits that 
are for evaluation and generation). Both parties save the de¬ 
cryption keys: the cloud saves the keys attained from the OT 
and the generator saves both possible keys that could have 
been selected by the cloud. The evaluator performs the OOT 
with the other parties to input the initial value into the pro¬ 
gram. There is no input by the generator so the generator’s 
input check does not execute. There is no partial input so 
that phase of the protocol is skipped. The garbled circuit to 
set the initial value is executed; while there is no output to 
the generator or evaluator, a partial output is produced: the 
cloud saves the garbled wire value, which it possesses, and 
the generator saves both possible wire values (the generator 
does not know what value the cloud has, and the cloud does 
not know what the value it has saved actually represents). 
The cloud also saves the circuit split. 

Saved memory after the program execution (when the 
evaluator inputs 0 as the initial value): 

Count 

0 

Saved Guests 


Guest 1 then enters the building and executes the pro¬ 
gram, entering his name (“Guest 1”) as input. 

Protocol in Brief for Second Program: In this second 
program, the cut-and-choose OT is not executed. Instead, 
both the generator and cloud load the saved decryption key 
values, hash them, and use those values for the check and 
evaluation circuit information (instead of attaining new keys 
through an OT, which would break security). The new keys 
are saved, and the evaluator then performs the OOT for in¬ 
put. The generator does not have any input in this program 
so the check for the generator’s input is skipped. Since there 
exists a partial input, the generator loads both possible wire 
values and creates the partial input gates. The cloud loads 
the attained values, receives the partial input gates from 
the generator, and then executes (and checks) the partial 
input gates to receive the garbled input values. The garbled 
circuit is then executed and partial output saved as before 
(although there is more data to save for this program as 
there is a name present in the database). 

After executing the second program the memory is as fol¬ 
lows: 

Count 

1 

Saved Guests 
Guestl 

Guest 2 then enters the dwelling and runs the program. 
The execution is similar to the previous one (when Guest 1 
entered), except that it’s executed by Guest 2’s phone. 


At this point, the memory is as follows: 

Count 

2 

Saved Guests 
Guestl 
Guest2 


Guest 3 then enters the dwelling and executes the program 
as before. At this point, the memory is as follows: 

Count 

3 

Saved Guests 
Guestl 
Guest2 
Guest3 


Finally, the host runs the last program that outputs the 
count and the guests in the database. In this case the count 
is 3 and the guests are Guestl , Guestl , and Guests. 







